Subject: Issues with route-setup and RTP connection reuse

From: [email-masked] (Matthew Finlayson)
Date: Wed, 20 Apr 94 18:57:17 BST

Another couple of problems with the HPR spec, I'm afraid:

(1) Route Setup Protocol (9.2)

The specification is very unclear about the mechanism by which a route-setup
reply (be it positive or negative) is directed back to the origin node.
In the case of a negative reply no RSCV is included, in the case of a
positive reply the RSCV is included, but the route-setup does not carry
information to identify the origin node.

Eventually we noticed (in the description of the route-setup GDS (A.1.15))
that the route-setup GDS variable carries a FQPCID which is recorded in
intermediate nodes along the path of the setup.  The implication is clearly
that the intermediate nodes need to remember the previous hop to direct
the reply, and also to rescue the situation should a link fail during route-
setup (ie to create and send a route-setup failure back along the path,
similar to a directed locate.)

This area is currently poorly documented, and the approach does have a couple
of drawbacks:

-     the route-setup is not a state-less process
-     the route-setup requires intermediate storage during the life of the
      request.

An alternative (more elegant?) approach might be to accumulate the RANR() on
the way out and the FANR() on the way back (reversing the current process).
This would mean that the reply could be routed by means of the RANR().  The
origin node could, in addition, run a timer to detect if the route-setup
message gets lost somewhere along its path.

(2) Reuse of RTP connections (Figures 9-3, 10-2, 10-3, 10-4)

There seem to be problems with the reuse of an RTP connection in the reverse
of the original setup direction.  In order to reuse a connection, the RSCV
has to match (plus other conditions - see Condition A of figures 9-3, 10-2,
10-3 and 10-4).  This means that the destination has to reverse the RSCV
received on the first BIND to flow on an RTP connection in order to compare
it with RSCVs of BINDs flowing in the opposite direction.  Unfortunately, this
is not possible, since the destination node does not know the origin node-
name.  Effectively, this means RTP connections cannot be reused in reverse.

Have we missed some part of the protocol, or is this an issue?

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================